One way in which user privacy can be maintained is for a user to supply different identities to different service providers. These identities are referred to herein as service-specific identities. In such a case however it is necessary for the operator of a network for subscribers to provide an identity management service which can associate service-specific identities with authorised subscribers. It is also useful if an identity management provider can make authorisations not only on behalf of itself, but also on behalf of other service providers. This means that users can invoke personalised services without having to sign on separately on each service profile site.
This arrangement is known as identity federation and allows service providers to read a user's identity from a centralised place. A user does not have to provide all the service providers with specific identity information.
There are currently two significant authentication procedures specified for wireless communication networks where a user equipment (UE) in the form of a mobile terminal wishes to access a service from a service provider in the network. The so-called Liberty Alliance (LA) standard uses an authentication procedure where a liberty enabled client (LEC) is a client that has, or knows how to obtain, knowledge about the identity provider that the user wishes to use with the service provider. It specifies service-specific identity mapping at an identity provider (IDP). Each subscriber has multiple identities for accessing service providers (SP). A federation directory at the identity provider stores relations between users, their identities and the services. The identity provider asserts a service-specific identity towards the service provider who recognises the user by that service-specific identity. The ability to present different identities to different service providers allows subscriber privacy to be maintained. According to the Liberty Alliance standard, the user may avoid revealing his real identity when invoking services. Instead of revealing his real identity, the user can either invoke the services anonymously or use a pseudonym (a service-specific identity). The federation directory maps the user's real identity to his pseudonyms or service-specific identities so that the service provider will not know the real identity. With the pseudonym and the mapping service the service provider can access, for example, the user's location or presence state. This allows a service provider to use the pseudonym to access the location of the user from an identity service provider via the mapping in the federation database. The Liberty Alliance standard specifies signed HTTP/soap binding to be used for assertions. However, there are many existing services which are not aware of Liberty assertions but rely on other forms of “assertions” for access such as traditional public key certificates. An example of such a service is access control to corporate virtual private networks (VPNs).
Another existing form of authentication is 3GPP support for subscriber certificates (SSC) [3GPP TS 33.221]. This is implemented as a 3GPP generic authentication architecture (GAA) [3GPP TS 33.220] and specifies a way to request a subscriber certificate for a specific identity from the certificate authority (CA). In this case, the specific identity is the identity of the user, and is not service-specific. According to the GAA/SSC technique, generic bootstrapping architecture (GBA) implanted at the user equipment authenticates the user equipment in conjunction with an authentication server at the service provider, and they agree on a shared key material. The generic bootstrapping architecture delivers the shared key material to a certificate authority CA. The user equipments generates an asymmetric public/private key pair and requests certification from the certificate authority. If authorised, a certificate is returned which associates the public key with the identity of the requesting user. The certification procedure is protected by the shared key material.
Mobile operators can authenticate their mobile subscribers using USIM, ISIM, user name/password pair or X.509 public key certificates. In the case of certificates, the authenticated identity is in the subjectName field or in the SubjectAltName extension of the certificate [RFC 3280].
The 3GPP/GAA/SSC authentication procedure does not have a mechanism to indicate the service provider that the subscriber wants to access. Only the identity of the user can be indicated and authenticated by the certificate. There is no support for certificate based authentication of multiple identities or service-specific identities. Although the SubjectAltName extension can be used to carry multiple identities and service-specific identities, the problem is that the user equipment needs to be able to indicate during the certification procedure the intended identity or identities, i.e. service or services it plans to use the certificate with. It does not want to put all the possible identities into one certificate, because discovering the bindings between different identities would be become very easy since the certificate is public.